Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@block/internal/submitting/da_submitter_integration_test.go`:
- Around line 101-110: The test currently calls daSubmitter.Close() only at the
end, risking resource leaks if earlier assertions fail; after creating the async
submitter (the daSubmitter variable), ensure cleanup is guaranteed by
registering a deferred close or t.Cleanup call—e.g., immediately after
daSubmitter is constructed call defer daSubmitter.Close() or t.Cleanup(func(){
daSubmitter.Close() }) so the Close() method on daSubmitter always runs even if
the test fails early.

In `@block/internal/submitting/da_submitter_test.go`:
- Around line 216-218: The test currently calls submitter.Close() after
assertions which can leak the submitter's async worker if an assertion fails;
change the teardown to run immediately after setup by invoking defer
submitter.Close() (or t.Cleanup(func(){ submitter.Close() })) right after the
submitter is created so Close() always runs even on test failures — update the
tests that call submitter.SubmitHeaders(...) and later submitter.Close() (e.g.,
the cases around SubmitHeaders and the other similar test) to use deferred
cleanup instead.

In `@block/internal/submitting/da_submitter.go`:
- Around line 388-398: The datalayer success branch uses res.SubmittedCount
directly which can be 0 or >len(marshaled) and cause infinite loops or panics;
in the datypes.StatusSuccess case (around res.SubmittedCount handling) validate
that submitted := int(res.SubmittedCount) is >0 and <= len(marshaled) before
calling onSuccess or advancing the window (marshaled = marshaled[submitted:]);
if submitted==0 treat as a reject/error (update rs.Attempt or return/log and do
not spin) and if submitted>len(marshaled) treat as malformed input (log/error
and reject) so only a validated count is passed to onSuccess and used to slice
marshaled.

In `@block/internal/submitting/submitter.go`:
- Around line 236-250: The code enqueues a batch as in-flight via
GetPendingHeaders/GetPendingData but if s.daSubmitter.SubmitHeaders or
SubmitData returns an immediate error the in-flight claim is never released;
update the error path in submitter.go around s.daSubmitter.SubmitHeaders and the
analogous SubmitData call so that before logging or returning on synchronous
error you call s.cache.ResetInFlightHeaderRange(headers[0].Height(),
headers[len(headers)-1].Height()) (and for data use the corresponding
ResetInFlightDataRange with the first/last data heights), then proceed to
log/handle the error (including the existing ErrOversizedItem handling) so the
claimed heights are retried.

---

Outside diff comments:
In `@block/internal/cache/pending_base.go`:
- Around line 80-96: getPending() currently reads pb.lastHeight
(pb.lastHeight.Load()) outside the pb.inFlightMu critical section and then
clones pb.inFlightClaims and pb.gaps, which allows an interleaving with
setLastSubmittedHeight() that trims those slices and updates lastHeight causing
findAvailableRange() to return already-acknowledged heights; fix by moving the
read of pb.lastHeight inside the same pb.inFlightMu.Lock()/Unlock() block where
you clone inFlightClaims and gaps so lastHeight and the in-flight ranges are
read atomically, and apply the same locking discipline to
setLastSubmittedHeight() (acquire pb.inFlightMu while trimming
inFlightClaims/gaps and updating pb.lastHeight) to prevent races when
findAvailableRange, getPending, and setLastSubmittedHeight interact.

In `@block/internal/submitting/da_submitter_tracing.go`:
- Around line 33-61: The current tracedDASubmitter starts a span in
SubmitHeaders (and similarly in SubmitData) but defers span.End(), which closes
the span before async work completes; instead remove the immediate defer
span.End() and wrap the onSubmitSuccess and onSubmitError callbacks with
closures that record errors/status on the span and call span.End() when the
async completion path runs; i.e., in tracedDASubmitter.SubmitHeaders and
SubmitData, create wrappedOnSuccess := func(){ span.SetStatus(codes.Ok, "");
onSubmitSuccess(); span.End() } and wrappedOnError := func(err error){
span.RecordError(err); span.SetStatus(codes.Error, err.Error());
onSubmitError(err); span.End() } (or equivalent wrappers matching original
signatures) and pass those to t.inner.SubmitHeaders/SubmitData so the span
lifetime and annotations reflect actual completion.

---

Nitpick comments:
In `@block/internal/cache/pending_data.go`:
- Around line 88-90: Add a Go doc comment for the exported method
ResetInFlightDataRange on type PendingData: describe what the method does, its
parameters (start, end uint64) and any important behavior or side-effects (it
delegates to pd.base.resetInFlightRange to reset the in-flight data range).
Place the comment immediately above the func declaration for
ResetInFlightDataRange so it satisfies Go exported identifier documentation
guidelines.

In `@block/internal/cache/pending_headers.go`:
- Around line 83-85: Add a Go doc comment for the exported method
PendingHeaders.ResetInFlightHeaderRange describing its purpose and behavior:
explain that it resets the in-flight header range tracked by the PendingHeaders
instance between the inclusive start and end uint64 indices, mention any side
effects (it delegates to ph.base.resetInFlightRange), and document the
parameters (start, end) and any expectations (e.g., inclusive bounds or
preconditions). Place the comment immediately above the ResetInFlightHeaderRange
method.

In `@block/internal/submitting/submitter_test.go`:
- Around line 424-440: The fakeDASubmitter currently drops the provided
callbacks in SubmitHeaders and SubmitData; update these methods (SubmitHeaders
and SubmitData on fakeDASubmitter) to call the supplied on-success and on-error
callbacks when they are non-nil so the test exercises the full success/error
lifecycle (e.g., invoke the success callback when you want the fake to simulate
success, or invoke the error callback with a test error to simulate failure),
while preserving the existing signaling to chHdr/chData; alternatively add a
focused test that uses a fake submitter which invokes those callbacks to assert
timestamps and in-flight cache resets.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@block/internal/submitting/da_submitter.go`:
- Around line 384-395: The code uses res.SubmittedCount directly which can be 0
or >len(marshaled); validate it before slicing and advancing. In the
datypes.StatusSuccess branch (symbols: res.SubmittedCount, marshaled, onSuccess,
rs.Next, reasonSuccess, pol) ensure submitted := int(res.SubmittedCount) is
checked: if submitted <= 0 treat as no progress (do not reset backoff — call
rs.Fail or return to avoid infinite loop), if submitted > len(marshaled) cap it
to len(marshaled) before calling onSuccess and slicing; only advance marshaled
and call rs.Next when a positive, bounded submitted value was applied.

---

Nitpick comments:
In `@block/internal/submitting/da_submitter.go`:
- Around line 326-331: The callback parameter onError in da_submitter.go is used
to signal both actual errors and graceful completion by calling onError(nil) for
empty batches/cancellations; update the code to make this contract explicit by
either renaming the parameter from onError to onComplete (and update all call
sites and related tests) or by adding a clear doc comment on the onError
parameter/signature (and any public type that exposes it) stating that a nil
argument indicates graceful termination/no-retry, while a non-nil error
indicates a retryable/failure condition; ensure you update comments and any
place that inspects the value (e.g., callers that use errors.Is(err,
common.ErrOversizedItem)) to reflect the new name or documented behavior.

In `@block/internal/submitting/submitter.go`:
- Around line 249-260: The onError closure should not log when err is nil: after
calling s.cache.ResetInFlightHeaderRange(headers[0].Height(),
headers[len(headers)-1].Height()) (if headers present), add an early guard if
err == nil { return } so you skip the error handling below; keep the
oversized-item check (errors.Is(err, common.ErrOversizedItem)),
s.logger.Error().Err(err).Msg("failed to submit headers"), and
s.sendCriticalError(...) as-is for non-nil errors.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@block/internal/submitting/da_submitter.go`:
- Around line 227-235: The success callback passed into submitWithRetry (in the
s.wg.Go closures that call postSubmit and onSubmitSuccess) incorrectly always
slices from the start (headers[:submittedCount] /
signedDataList[:submittedCount]) and thus re-processes already-handled items on
partial successes; fix this by introducing and capturing a local cumulative
offset (e.g., submittedOffset) alongside the closure, have the callback use
headers[submittedOffset:submittedOffset+submittedCount] (and signedDataList
likewise), call postSubmit with that slice, then increment submittedOffset +=
submittedCount inside the callback so subsequent partial successes advance
correctly; apply the same change to the other closure that handles
signedDataList (the block around submitWithRetry at the second occurrence).

---

Outside diff comments:
In `@block/internal/submitting/da_submitter_tracing.go`:
- Around line 33-61: The current tracedDASubmitter.SubmitHeaders creates a span
and defers span.End(), but the inner SubmitHeaders only enqueues work so the
span ends too early and misses async failures; change the wrapper to either (a)
create two spans (an immediate "enqueue" span that ends on return and a separate
"submission" span that is ended by a real completion callback), or (b) wrap the
provided onSubmitSuccess and onSubmitError with a new finalizing callback that
records errors, sets span status, and ends the span when the overall submission
is truly finished; apply the same pattern to the other traced methods mentioned
(lines 64-97) so spans cover end-to-end submission rather than just enqueue
latency, and reference tracedDASubmitter.SubmitHeaders, the inner SubmitHeaders
call, and the onSubmitSuccess/onSubmitError callbacks when implementing the
change.

In `@block/internal/submitting/submitter.go`:
- Around line 153-168: In Submitter.Stop(), currently s.daSubmitter.Close() is
called before waiting for s.wg which allows goroutines to call
SubmitHeaders/SubmitData after Close() starts; change the order so you first
call s.cancel() (if non-nil) to stop producers, then wait for s.wg (with the
existing timeout/done pattern), and only after the wait completes or times out
call s.daSubmitter.Close(); ensure Submitter.Stop retains the timeout warning
path and uses the same s.wg, s.cancel, and s.daSubmitter.Close() symbols.

---

Duplicate comments:
In `@block/internal/submitting/da_submitter_test.go`:
- Around line 216-218: Register the submitter.Close cleanup immediately after
setupDASubmitterTest returns the submitter so the async worker is always joined
even if an assertion fails; i.e., right after obtaining the submitter variable
in the test, call t.Cleanup(func(){ submitter.Close() }) (and remove or leave
any later explicit submitter.Close() calls as desired) to ensure teardown; apply
the same change to the other test case that creates a submitter (the block that
currently calls submitter.Close() later).

In `@block/internal/submitting/da_submitter.go`:
- Around line 383-395: Validate res.SubmittedCount from the DA client before
using it: ensure it's within [0, len(marshaled)] and handle the zero-case by
advancing the window (call rs.Next(reasonSuccess, pol)) instead of treating it
as full success; compute a safe int value (e.g., capSubmitted := max(0,
min(int(res.SubmittedCount), len(marshaled)))) then call onSuccess(capSubmitted,
res.Height) and log using capSubmitted, slice marshaled =
marshaled[capSubmitted:] only when capSubmitted > 0, and log or error when
res.SubmittedCount is out-of-range to avoid panics in this block that contains
res.SubmittedCount, onSuccess, marshaled, rs.Next, reasonSuccess, pol, and
s.logger.Info().

---

Nitpick comments:
In `@block/internal/cache/pending_data.go`:
- Around line 84-95: Add Go doc comments for the exported PendingData methods:
NumPendingDataTotal, SetLastSubmittedDataHeight, and ResetInFlightDataRange. For
NumPendingDataTotal and ResetInFlightDataRange add brief one-line comments
describing what they return/affect (e.g., number of pending data entries and
that ResetInFlightDataRange clears the in-flight range between start and end),
and for SetLastSubmittedDataHeight document the parameter and its effect on
PendingData state; follow the style and phrasing used by other public cache APIs
in the package.